-
Notifications
You must be signed in to change notification settings - Fork 34
#185: Added subClassOfInShapesGraph parameter #447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
At risk of overcomplicating things - would it be worth |
@jeswr there is already sh:entailment to activate other inferencing. And it is under complete control of the user which graph to pass into the engine as shapes graph. That graph may have been pre-processed with OWL to infer additional rdfs:subClassOf axioms. As the above IMHO doesn't need a formal parameter to the engine, I wanted to however spell out the new flag because it does need a parameter as it changes how some terms (SHACL Instance) behave. |
Where's the list of all parameters? The whole "implementation controls" area seems to sit uneasily between implementation and standardization. |
Not sure if the discussion is best here or on #185. Added a general comment on the issue -- #185 (comment) |
I am not aware of other flags or parameters for the engine, but they could be grouped into an appendix if we define more. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am approving this pull request (PR) because I favour using instead of over in addition to, as the latter would add more complexity. Also, if we gather other flags or parameters, we can add them in an appendix in another PR.
No test? |
@afs correct, no test because the feature is optional ("SHOULD") and we don't have any mechanism in the test case framework to set this flag. |
@HolgerKnublauch — SHOULD statements are as deserving of tests as MUST statements. Failing a SHOULD test should not result in failure of conformance report, but should result in reporting that failure of SHOULD such that deployers can differentiate between two implementations that both satisfy all MUST statements but satisfy different (whether counts or instances) SHOULD statements. |
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Jesse Wright <63333554+jeswr@users.noreply.github.com>
Ok, the semantics of the flag have been changed to be the union of shapes and data graphs. Please re-check and let me know any remaining concerns. |
SHACL processors SHOULD offer a parameter <code>subClassOfInShapesGraph</code> that, if set to <code>true</code>, | ||
should alter the definition of <a>SHACL Type</a> so that the <code>rdfs:subClassOf</code> triples are queried | ||
from the <a>shapes graph</a> in addition to the <a>data graph</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking remark, anyone feel free to Resolve this thread: #431 may open an avenue for writing tests for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This overall looks good to me. I left a few minor suggestions, but didn't see anything meriting blocking with the "Request changes" review.
I think I'm now understanding @afs 's question on parameters. We have subClassOfInShapesGraph
in this PR, and potentially one representing conformance-disallowance depending on how #453 shakes out.
Definitely if we have a second parameter to accompany subClassOfInShapesGraph
, a table, section, or appendix should go in for indexing specification-defined parameters.
I could probably be swayed to wait to sketch that table/section, but request if the decision is to wait that an Issue be posted to track it.
Tests are more than just compliance. They also perform the role of another explanation of the feature. For a large system such as SHACL, tests are valuable implementation resources. e.g. where would constraints be affected when this optional feature is activated? |
Co-authored-by: Alex Nelson <alexander.nelson@nist.gov>
Co-authored-by: Alex Nelson <alexander.nelson@nist.gov>
Closes #185
Added Andy and Ashley as reviewers too, to check if this is implementable from their engines point of view. The main difference is that instead of
it would become
And it's an optional feature...